You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A recent PR, #16489, fixed an issue where action_logs.created_by was being recorded as null and action_logs.created_at was being recorded incorrectly when bulk checking in accessories (other bulk checkin entries recorded correctly).
This PR
This PR adds a command, snipeit:fix-bulk-accessory-action-log-entries, to fix both created_at and created_by for the entries mentioned above.
created_at was being recorded as ~1970-01-01 00:00:01 and since updated_at was recorded correctly, we can use created_at being in 1970 as a way to update created_at to the updated_at timestamp.
created_by is a little more tricky. Since other bulk checkins were being recorded correctly, this command looks to find the user_id by using each action log entry that has the 1970s issue mentioned above to find a matching log entry that has created_by populated. Put another way, if a user did a bulk checkin including accessories, where created_at and created_by would be incorrect, and the checkin also included checkins for assets, licenses, etc, we can use those entries to populate created_by.
Example output from a dry-run:
└─[$]› art snipeit:fix-bulk-accessory-action-log-entries --dry-run
This is a DRY RUN - no changes will be saved.
Found 5 logs with incorrect timestamps:
+-----+------------+---------------------+---------------------+
| ID | Created By | Created At | Updated At |
+-----+------------+---------------------+---------------------+
| 474 | | 1970-01-01 00:00:01 | 2025-03-11 22:47:44 |
| 478 | | 1970-01-01 00:00:01 | 2025-03-11 22:50:32 |
| 483 | | 1970-01-01 00:00:01 | 2025-03-11 22:56:14 |
| 501 | | 1970-01-01 00:00:01 | 2025-03-11 23:20:03 |
| 503 | | 1970-01-01 00:00:01 | 2025-03-11 23:21:32 |
+-----+------------+---------------------+---------------------+
DRY RUN. NOT ACTUALLY UPDATING LOGS.
Processing log id:474
Updating log id:474 created_by to 1
Updating log id:474 from 1970-01-01 00:00:01 to 2025-03-11 22:47:44
Processing log id:478
Updating log id:478 created_by to 1
Updating log id:478 from 1970-01-01 00:00:01 to 2025-03-11 22:50:32
Processing log id:483
Updating log id:483 created_by to 10
Updating log id:483 from 1970-01-01 00:00:01 to 2025-03-11 22:56:14
Processing log id:501
No created_by found for log id:501
Skipping updating this log since no similar log was found to update created_by from.
Processing log id:503
No created_by found for log id:503
Skipping updating this log since no similar log was found to update created_by from.
DRY RUN. NO CHANGES WERE ACTUALLY MADE.
A New Console Command Introduced
A new console command has been added to the system: FixBulkAccessoryCheckinActionLogTimestamps. This is planned to rectify specific inaccuracies identified in our log timestamps and in cases where the created_by value is missing in bulk check-in entries.
Testing Functionality Added
An additional feature now allows users to simulate data alterations without actually applying changes in the database by using a --dryrun option. This helps to review and verify the potential changes beforehand.
Detection of Incorrect Log Timestamps
A logic has been incorporated to find and list logs possessing wrong timestamps, particularly ones misdated around the 1970s. This list is then presented in a structured table format for easy interpretation.
Method to Retrieve Missing Created_by Attributes
In cases where bulk check-in entries are missing a created_by attribute, a method has been developed to find a similar log and extract the information from there.
Refined created_at and created_by Log Entries
Amendments have been made to these log entries, retrieved from similar logs. This reconditions and standardizes the logs maintaining its database integrity.
Confirmation before Updates
Updates to the database entries will only take place once they are reviewed and confirmed by the user. There is an option to skip updates if desired, ensuring full control over data modifications.
This looks great, thank you @marcusmoore! Regarding your question, I think maybe backing up by default but allowing a --skip-backup flag might be useful.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Background
A recent PR, #16489, fixed an issue where
action_logs.created_bywas being recorded as null andaction_logs.created_atwas being recorded incorrectly when bulk checking in accessories (other bulk checkin entries recorded correctly).This PR
This PR adds a command,
snipeit:fix-bulk-accessory-action-log-entries, to fix bothcreated_atandcreated_byfor the entries mentioned above.created_atwas being recorded as~1970-01-01 00:00:01and sinceupdated_atwas recorded correctly, we can usecreated_atbeing in1970as a way to updatecreated_atto theupdated_attimestamp.created_byis a little more tricky. Since other bulk checkins were being recorded correctly, this command looks to find theuser_idby using each action log entry that has the 1970s issue mentioned above to find a matching log entry that hascreated_bypopulated. Put another way, if a user did a bulk checkin including accessories, wherecreated_atandcreated_bywould be incorrect, and the checkin also included checkins for assets, licenses, etc, we can use those entries to populatecreated_by.Example output from a dry-run: